Each business use case will be assigned to a subset of the business-modeling team, who will describe it in detail.
Acting as business designer, this subset team will complete the definition of the business use case and lead a review
session for it. Other members of the business-modeling team are invited to this review session to act as business-model
reviewers. The business designers might also invite representatives of the stakeholders to the project, such as end
users.
The purpose of this activity is to:
-
Detail the definition of the business use cases.
-
Describe how the business use cases support the business goals.
-
Verify that the business use case correctly reflects how business is conducted.
It may be necessary to restructure the Business Use Case Model to improve understanding or readability, but
restructuring should not be attempted too early. This is because it is best to wait until the level of understanding of
the business use cases has become sufficient enough to prevent the introduction of unnecessary complexity during
restructuring. Usually, any necessary restructuring should be performed after this activity has been reached.
Depending on the level at which the business use cases have been defined, it may be necessary to refine them
(Task: Refine a Business Use-Case) so that the refined business use case has a scope
for which it is useful and feasible to specify the flow in detail (and later construct the realization of that
flow).
Common sub-flows might be identified, as well as relationships between business use cases. Business use cases may also be grouped into
packages. Restructuring should occur only to make the model more understandable or manageable.
Once the business use cases have become somewhat stabilized, the highest
priority ones must be detailed. This entails further describing each step of the business use case, as well as
completing its remaining properties (preconditions, post-conditions, and special requirements). While detailing the
highest priority business use cases, certain quantitative and qualitative requirements governing their behavior might
be discovered (for example, required turnaround time or process flexibility). If these requirements are applicable to
the business use case only, they should be captured in the Special Requirements property of the business use case.
Otherwise, they should be captured in the Supplementary Business Specification.
The Business Use Case Model must be reviewed to ensure that it remains
succinct and understandable to all stakeholders. The following must also be reviewed to ensure that the requirements
are clear and realistic: Supplementary Business Specification.
|
This content developed or partially developed by Empulsys BV.
|
|
|
